Currently, many devices require real-time operating systems for optimal functioning, while needs for non-real-time applications are still prevalent. With the proliferation of processing architectures such as multiple core processors, it may be useful to fulfill both needs in a single platform, which is made feasible by the increasing complexity of processor cores.
Virtualization has long been used to service multiple application domains safely and reliably. This allows for load balancing as well as robustness. However, at present real-time operating systems cannot easily exist as truly virtualized entities without sacrificing responsiveness. This is caused in large part by the process of handling interrupts in a virtualized environment.
In some arrangements, a program such as a hypervisor, also referred to as a virtual machine manager (VMM), presents a virtual operating platform to multiple operating systems known as guests, or guest operating systems. The term “virtual machine” (VM), which represents an entity managed by the hypervisor, generally refers to a completely isolated guest operating system installation within a normal host operating system.
The hypervisor may be installed on a hardware host whose task is to run the guest OS. When applications run in a virtualized environment, the hypervisor manages interrupts for an application of a given guest OS. For example, when an interrupt meant for a first guest OS is delivered to the hypervisor, a virtual machine (VM) exit is triggered, in which a transition from guest execution to host execution takes place. After an interrupt is successfully handled in the hypervisor, a subsequent VM entry takes place and the interrupt is injected into the guest OS. The guest OS then resumes execution and now sees the interrupt injected by the hypervisor as an interrupt generated from one of the guest OS' own devices. The handling of interrupts can result in an interrupt latency having a duration that is many times that of the interrupt latency engendered when a non-virtualized application is running directly on the hardware host. Since many applications are sensitive to interrupt latency, this increased latency, among other factors, restricts the widespread adoption of virtualization.
It is with respect to these and other considerations that the present improvements have been needed.